home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 927 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.5 KB
  1. Subject: Re: MiNT TO UNIX
  2. Date: Thu, 20 Jan 94 21:16:28 CET
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <199401180757.AA09360@avignon.daimi.aau.dk>; from "Christian Lynbech" at Jan 18, 94 8:57 am
  5. Message-Id: <9401202016.AA00190@jelal.north.de>
  6.  
  7. Christian Lynbech writes:
  8.  
  9. > No, but given the size of the standard atari B/W monitor, the text
  10. > screen isn't that bad.  ...
  11.  
  12.  and given the current performance of GEM... :)  but thats what virtual
  13. consoles are for, then you can use GEM and still have fast text screens.
  14. (next update coming soon...)
  15.  
  16. > Chris also writes:
  17. > > > [...stuff about i) fs standards or ii) making porting/configuring easy...]
  18. > > Definitely the second option, but I'd certainly settle for #1 in the
  19. > > mean-time.  :-)
  20. > 
  21. > I do not see a contradiction here.
  22.  
  23.  what i ment is when we can assume that ii) everyone has got a working
  24. compiler etc. like on unix then we would not have to hack together
  25. binary distributions for packages like Cnews that were never ment to be
  26. installed from binaries.  i.e. it would save work for the people doing
  27. the ports and noone would be stuck with other peoples configuration
  28. options because they are compiled into the binaries... (and these are
  29. not just paths and directories.)
  30.  
  31. >  For one, a decent bourne shell and
  32. > a fully working test program, lets you configure most GNU software
  33. > pretty easy, already now.
  34.  
  35.  exactly.
  36.  
  37. >  But some fs standard would give additional
  38. > benefits:
  39. > 
  40. > 1) Less need of patching.
  41. > Adding some environment variable requirement, probably means that you
  42. > still need to patch even GNU packages, and this is somewhat a pain,
  43. > when the next version of (say) the fileutils are out.
  44.  
  45.  yup.  making every compile-time option an environment variable is
  46. not a good solution...
  47. > 
  48. > 2) Not absolutely dependent on sources.
  49. > If you want a UNIX setup, you are pretty much required to have the
  50. > sources so you can configure to your specific setup. There is no
  51. > standard, so in theory you risk that one guy uploads the GNU diffutils
  52. > configured with all programs in /usr/local/bin and another guy uploads
  53. > RCS which expects diff to be A:\GNUBIN so that you just can't win.
  54. > This project is also a commitment to ensure that there are utilities
  55. > working within the standard (me thinks).
  56.  
  57.  agreed.  for many things standardized search paths are enough to
  58. exchange binaries so we certainly should have them.
  59.  
  60.  cheers
  61.     Juergen
  62. -- 
  63. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  64.                                 ...ohne Gewehr
  65. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  66.